Problem

GPU CRUD benchmark records could not reliably distinguish managed vs fully-managed GPU pools. The stable azure-mgmt-containerservice SDK does not model gpuProfile.nvidia.managementMode, so a fully-managed pool's mode is silently dropped from the nodepool_info read-back — leaving only the pool name (a brittle string) to tell them apart. On top of that:

• MIG single vs mixed was dropped on scale operations.
• scale_node_pool never recorded the managed flag at all.

What this does

Derive a normalized set of GPU metadata from the operation input flags (not the lossy AKS read-back) and attach it to create, scale, and progressive-scale operations:

• Thread gpu_mig_strategy through the scale path (main.py → NodePoolCRUD → AKSClient → _progressive_scale) and through execute.yml so scale-up/scale-down records are accurate.
• Echo the metadata to the console on each op (GPU pool metadata: gpu_mode=… mig_enabled=… …) so it is visible in pipeline logs, not only in the uploaded results.json.

Robustness / review hardening

• gpu_instance_profile / gpu_mig_strategy are Azure-only MIG inputs; the AWS CRUD does not accept them (no **kwargs). They are now only forwarded when --cloud azure, avoiding a TypeError on AWS runs.
• _gpu_mode_metadata normalizes flag combinations so records are always internally consistent: managed/MIG only apply to a GPU pool; MIG only applies to fully-managed pools (dropped otherwise); invalid gpu_mig_strategy is rejected.
• execute.yml gates --gpu-instance-profile / --gpu-mig-strategy on ENABLE_MANAGED_GPU==true (create, scale-up, scale-down) so MIG flags are only emitted for fully-managed pools.

Incidental fixes (folded in)

• Scale poller timeout 20m → 30m (_begin_update_with_retry): A100 MIG node provisioning could exceed the old 1200s timeout, causing spurious scale failures.
• verify_nvidia_smi_on_node MIG-single race: the readiness wait broke as soon as the nvidia.com/gpu key appeared, even with value 0. A freshly-scaled MIG-single node registers nvidia.com/gpu=0 before publishing its MIG instances, so the check raced in, read 0, and skipped the node with a misleading "has no GPUs" warning. Now waits for a positive GPU/MIG count.

Verification

Validated end-to-end on the GPU Cluster CRUD pipeline — latest run build 71637 (commit e07404fa, succeeded), A100 chain managed → fully_managed → MIG-mixed → MIG-single.

Recorded metadata in the published results.json is correct on every create/scale_up/scale_down op (confirmed across builds 71550/71623/71637):

Also confirmed in build 71637 logs:

• Console echo prints per op, e.g. GPU pool metadata: gpu_mode=managed enable_managed_gpu=False mig_enabled=False gpu_instance_profile=None gpu_mig_strategy=None.
• The MIG-single nvidia.com/gpu=0 race is fixed — a100migsin is no longer skipped.
• No scale-poller timeout (30-min bump applied).

managed vs fully_managed are now distinguishable, and MIG mixed vs single is recorded on scale ops as well as create.

Known / out-of-scope (not introduced by this PR)

Observed in build 71637 but unrelated to these changes:

• A100 vCPU quota exhaustion in southcentralus (ErrCode_InsufficientVCPUQuota, requested 192 / remaining 0) during an a100migmixed scale-up — environmental capacity, not a code issue.
• Managed-pool GPU advertisement: a100managed (driver-install) nodes did not advertise nvidia.com/gpu within the wait window, so nvidia-smi verification skipped them. This is pre-existing behavior (the prior code also waited and skipped, since the key never appears) — a device-plugin scheduling/timing issue on the managed A100 path, worth a separate follow-up.

Testing

• Unit tests for the metadata helper variants, normalization (MIG dropped for non-fully-managed, managed flag normalized without a GPU pool, invalid strategy rejected), scale-op metadata persistence, console echo, an AWS regression test asserting MIG kwargs are omitted for --cloud aws, and a verify_nvidia_smi_on_node regression test (node reports 0 then a positive count → verified, not skipped).
• End-to-end validated via build 71637 (tables above).